Obviously, the key to success in this rapidly changing marketplace is to leverage the previous work done for a design into as many subsequent designs as possible. STMicroelectronics (Geneva) has amassed a huge library of intellectual property (IP). Effective IP reuse not only saves valuable time, but also helps to ensures application software compatibility between different products. To facilitate design reuse and encourage good design practices, we have developed internal rule-checking tools and a Blue Book reference manual for hardware IP designs. Our Blue Book is a superset of the work done by the VSIA (Virtual Socket Interchange Alliance), of which STMicro is an active member. Designers who respect our design conventions can significantly reduce the number of unpleasant surprises that can arise as design blocks are integrated into an SOC.

The single most important thing we have done to improve design productivity, and to help deliver new products to market quickly, is to develop SOC design platforms. We develop the base architecture and then our customers, either internal product groups or external design teams at systems houses, build on the platforms and customize for a particular application.

Defining platform-based design

Just what is platform-based design? We define platform-based design as the creation of a stable microprocessor-based architecture that can be rapidly extended, customized for a range of applications, and delivered to customers for quick deployment. The processor core can be a DSP, a microcontroller, or several of each. We have used the CoWare (Santa Clara, CA) N2C design system to create and customize the platform and have found that it provides an extensible base architecture for a family of platforms.

Subsequently, adding different hardware or software to the base platform is a straightforward process by which to create several derivatives. In this manner, a family of products can be delivered, instead of a single product, and future generations can build on the original hardware and software investments (see Figure 1). In turn, this strategy dramatically reduces time to market while decreasing development and production costs.

We estimate that each platform can lead to four or five products per year and, frequently, ten or more products over the lifetime of the platform. In fact, now that we have developed so much experience with platform-based design, we are able to assemble a digital consumer platform in less than a week using existing IP.

The question needs to be asked: Isn't every design a potential design platform? In fact, it would be wonderful if it was that easy. But, traditional ASIC design makes swapping out major IP blocks during development extremely difficult, if not impossible, because all of the interfaces to those blocks that are hard coded into the design.

Our design methodology helps to solve this problem by separating the communications interfaces from the functionality of the IP blocks. When designing a platform, we generate the appropriate hardware interfaces using the interface synthesis capabilities of CoWare N2C, as well as the software interfaces to the hardware (for instance, the memory maps for registers and the software drivers). This makes swapping out one piece of IP an easier process and also allows designers to evaluate the potential of one piece of IP in a design versus another.

The first platform we developed using our current base of tools was the UPP (Universal Processor Phone) for mobile phones. This platform included the ST100 DSP megacell, modeled at the bus-cycle accurate level. We used our internally developed AVP (Architecture Validation Platform) to make sure our high-level abstraction was correct. Then we refined the model until we had a complete and fully synthesized hardware base for our platform.

Clearly, design platforms aren't just for mobile phones. We are using platform-based design techniques for a wide range of wireless and wireline devices and consumer products, including digital television, DVD players, and set-top boxes. In the past year, we have developed many platforms using a variety of processors (for example, the ARM7, ST20, ST40, DSP950, and MMDSP) and our platforms have become quite complex-a recent set-top box design employed five CPUs. We fully expect platforms to extend into an even wider range of applications in the coming months and years.

Tools of the trade

We have a toolkit that allows us to use our standardized bus as the backbone of any integration between a processor and our library of digital consumer IP blocks, which has had a large impact on design productivity. The architecture of our STBus takes into account VSIA recommendations and consists of the following parts:

- One or more Interconnects, split into two parts:

- Node (Arbiter and Router)

- Converter (Type and Size)

- The Type Converter handles the different subset of interfaces:

- Peripherals - Type I

- Basic - Type II

- Advanced - Type III

- Pipelined - Type IV

- The Size Converter is used between two buses of different widths.

- The Buffer is used as a FIFO between two nodes.

- An Initiator initializes the requests onto the STBus.

- Peripherals or Targets include the memory and the registers mapped into memory, as well as dedicated peripherals.

We use CoWare N2C as an important part of our HW/SW co-design toolkit because it preserves the C software development environment for the software people, adds the necessary clocking to C to enable hardware designers to move C functionality into a hardware architecture, and co-exists with existing hardware in Verilog or VHDL. The tool also lets system architects capture, animate, and validate their concepts in clearly stated system specification. By creating detailed specifications, and testing the software and hardware against that specification throughout the design process, designers can avoid unpleasant surprises at the end of the design cycle and reduce overall development time.

Most designers are familiar with some form of the C language; today C is most often the language of choice for software algorithm descriptions. (We were early advocates of SystemC as a standard for IP reuse and model exchange and are very involved in the Open SystemC Initiative-OSCI.) A system-level model in C/C++ can be quickly simulated to validate and optimize the design, explore various algorithms, and provide the hardware and software development team with an executable specification of the system. On a particular project, our system designers first write system-level models in C++ or CoWareC.

Defining blocks

To create a repeatable process for development of a platform, we did more than assemble a toolkit; we standardized our design flow into one that allows us to define blocks at different abstraction levels (see Figure 2). As we progress along in our design, we simulate with a mix of abstraction level, dynamically using the same C testbench for the high-level and low-level models, which helps to ensure design consistency and accuracy.

Currently, our platform-based design flow is based on CoWareC and includes the following:

- Untimed level (UT)

- Bus-cycle-accurate shell level (Bcash)

- Bus-cycle accurate (BCA)

- Register-transfer C level (RTC), which is similar to RTL in VHDL or Verilog.

At the highest level, untimed, we're evaluating the functionality of the design. A processor hasn't yet been selected. Functional simulation verifies the interaction of the hardware and software algorithms.

At the Bcash level, we can get a cycle-accurate shell to model against the software. Here we pick a processor and use performance modeling to evaluate the speed of the execution code on the ISS (instruction set simulator). We can also evaluate the effects of the bus traffic on the overall performance. For example, if something doesn't meet performance goals in software, we can target that module to hardware.

Next, we incrementally move hardware BCA models into RTC descriptions. We synthesize the software drivers and hardware interfaces to speed the process. Synthesized components can include address decoding, interrupt priority encoding, arbitration units, memory mapped registers, program and data memory and controllers, interrupt service routines, boot code, methods to access memory mapped registers, and more. The result is a plug-and-play method that enables the rapid creation of many derivatives.

We also perform an RTC to VHDL (or Verilog) conversion (using CoWare N2C), but only a limited set of RTC constructs are converted in the process. To counter this tendency, we developed RTC analyzer tools to identify potential problem areas in the VHDL code and to set general design rules for the conversions. This allows us to eliminate a number of problems without costly co-simulations, which are much more time consuming in VHDL than in RTC.

After the RTC-to-VHDL translation, the VHDL code is co-simulated with an existing HDL simulator (VSS, Leapfrog, Modelsim, IKOS) or the code is co-emulated with Celaro to verify the HDL behavior.

A flexible approach

It's important that we constantly evaluate new tools as they come to market. We realize that, with the diverse types of designs we're working on, no one tool can do everything we need.

Subsequently, we have added interfaces to a number of tools required for specialized design requirements.

All of these tools are attached together through clear APIs and can be used, or not, depending on the needs of the design project.

Our design tool set must be flexible in order to meet a variety of needs throughout our organization. The tool set is continuously evaluated by our Center of Competence based in Meylan, France (called CMSA-Co-design and Modeling for System Architecture). Arexsys (Meylan, France) has developed an intermediate structure, called BEEF, which we use in order to synthesize, starting from an SDL (system-design language) description into BCA and/or RTC. In addition, using this technology we can translate an RTL block into RTC.

Esterel is a synchronous reactive language with a mathematical semantic. Esterel Studio from Esterel Technologies (Sophia Antipolis, France) is providing an interface for design entry such that we can capture the control part of the system using bubble charts, and modeling the finite state machines (hierarchical and communicating). We can synthesize from these bubble charts to BCA and/or RTC descriptions. Also, due to its formal definition, we are able to prove that these different levels of abstraction are functionally equivalent. Using SPW (Signal Processing Workshop) from Cadence (San Jose, CA), designers can define a variety of algorithms for data flow architectures, verify those algorithms, map their applications onto a CoWare platform, run simulations from the SPW environment, get traces, and validate the implementation.

We are currently wrapping the Denali (Palo Alto, CA) models of memories into the CoWare N2C environment in order to get various models including SRAM, SDRAM, and DDR. The same models are used in our design implementation environment, as well as in the verification environment. We recently started a pilot project with Cadence's VCC using our ST100 32-bit DSP core and the STBus as the two drivers. VCC provides a way to describe the architecture at a very high level. The VCC output provides the input for the CoWare N2C environment.

The customer's platform

So far, we discussed platform-based design from the standpoint of a design platform creator. But, it's also important to understand how our customers use the platforms we create. What we give them is a base they can expand upon. Everything in the base has been thoroughly tested so that we are confident that the software development tools work and the hardware works.

Now it remains for the customer to differentiate the platform for a particular application by building on the platform and synthesizing the interfaces between the base platform hardware and other hardware and software elements that need to be added. Hardware- hardware interface synthesis allows extensible platforms to be created with very limited knowledge of the functional specification. Generating a detailed application-programming interface (API) is also important in order to map embedded software to the target processors. This API consists of header files giving a comprehensive and clear link to the platform's memory map, and makefiles to help the software developer compile his program to the target processor correctly.

Just a few years ago, system-level design was very new; the technology wasn't a standard part of our design strategy. We had a solution that we kludged together for co-simulation involving VHDL and functional C. We often ran into problems with mismatches between the software drivers and the silicon if they weren't properly verified beforehand. At that time, we used Seamless from Mentor Graphics (Wilsonville, OR) and Synopsys' (Mountain View, CA) Eaglei. However, these functions are now included in the CoWare N2C tool.

The productivity improvements gained from platform-based design have had a major impact on our company. We're able to start software designs much earlier in the design process. In addition, the process allows us to quickly verify that our silicon will be functionally and architecturally correct. Also, we're successfully reusing major components throughout the organization; our product groups are now organized by application and include a library group charged with the task to generate reusable IP. Finally, we are able to accommodate many projects progressing in parallel and because we can do more, we've hired more people.

This is not to say that our process is perfect. We still worry about big, complex middleware like Windows CE on a set-top box. Windows CE is so complex that it can take a half-hour just to boot in simulation. So, among the many things on our wish list, we include an emulator powerful enough to run the core at hardware speed. This is why ST is pushing so hard to get a standard SCE-API (sales configuration engine-application programming interface) from all the vendors to build a decent solution. However, the technology is maturing rapidly, and we fully expect that our platform-based design process will continue to change and improve significantly with time.

Print this story	Send as e-mail